<!DOCTYPE html> 


<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>
  
    RFC 7160 - Support for Multiple Clock Rates in an RTP Session
  
</title>
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <style>

  @media only screen 
    and (min-width: 992px)
    and (max-width: 1199px) {
      body { font-size: 14pt; }
            div.content { width: 96ex; margin: 0 auto; }
        }
  @media only screen 
    and (min-width: 768px)
    and (max-width: 991px) {
            body { font-size: 14pt; }
            div.content { width: 96ex; margin: 0 auto; }
        }
  @media only screen 
    and (min-width: 480px)
    and (max-width: 767px) {
            body { font-size: 11pt; }
            div.content { width: 96ex; margin: 0 auto; }
        }
  @media only screen 
    and (max-width: 479px) {
            body { font-size: 8pt; }
            div.content { width: 96ex; margin: 0 auto; }
        }
  @media only screen 
    and (min-device-width : 375px) 
    and (max-device-width : 667px) {
            body { font-size: 9.5pt; }
            div.content { width: 96ex; margin: 0; }
        }
  @media only screen 
    and (min-device-width: 1200px) {
            body { font-size: 10pt; margin: 0 4em; }
            div.content { width: 96ex; margin: 0; }
        }
        h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 {
      font-weight: bold;
            /* line-height: 0pt; */
            display: inline;
            white-space: pre;
            font-family: monospace;
            font-size: 1em;
      font-weight: bold;
        }
        pre {
            font-size: 1em;
            margin-top: 0px;
            margin-bottom: 0px;
        }
  .pre {
      white-space: pre;
      font-family: monospace;
  }
  .header{
      font-weight: bold;
  }
        .newpage {
            page-break-before: always;
        }
        .invisible {
            text-decoration: none;
            color: white;
        }
        @media print {
            body {
                margin-top: 5em;
                font-family: monospace;
                font-size: 10.5pt;
            }
            h1, h2, h3, h4, h5, h6 {
                font-size: 1em;
            }
        
            a:link, a:visited {
                color: inherit;
                text-decoration: none;
            }
            .noprint {
                display: none;
            }
        }
  @media screen {
      .grey, .grey a:link, .grey a:visited {
    color: #777;
      }
            .meta-info {
                background-color: #EEE;
            }
            .top {
                border-top: 7px solid #EEE;
            }
            .pad {
                padding-top: 7px;
                line-height: 24px;
                padding-bottom: 4px;
            }
            .bgwhite  { background-color: white; }
            .bgred    { background-color: #F44; }
            .bggrey   { background-color: #666; }
            .bgbrown  { background-color: #840; }            
            .bgorange { background-color: #FA0; }
            .bgyellow { background-color: #EE0; }
            .bgmagenta{ background-color: #F4F; }
            .bgblue   { background-color: #66F; }
            .bgcyan   { background-color: #4DD; }
            .bggreen  { background-color: #4F4; }

            .legend   { font-size: 90%; }
            .cplate   { font-size: 70%; border: solid grey 1px; }
  }
    
     

.bgwhite  { background-color: white; }
.bgred    { background-color: #F44; }
.bggrey   { background-color: #666; }
.bgbrown  { background-color: #840; }            
.bgorange { background-color: #FA0; }
.bgyellow { background-color: #EE0; }
.bgmagenta{ background-color: #F4F; }
.bgblue   { background-color: #66F; }
.bgcyan   { background-color: #4DD; }
.bggreen  { background-color: #4F4; }

.draftcontent { margin-top:0px !important;}


    </style>

    
  <link rel="alternate" type="application/atom+xml" title="Document changes" href="/feed/document-changes/draft-ietf-avtext-multiple-clock-rates/">
  <meta name="description" content="Support for Multiple Clock Rates in an RTP Session (RFC )">


    
    <link rel="shortcut icon" href="https://www.ietf.org/lib/dt/7.46.0/ietf/images/ietf-icon-blue3.png">
    
    <link rel="apple-touch-icon" href="https://www.ietf.org/lib/dt/7.46.0/ietf/images/apple-touch-icon.png">
  </head>

  <body style="padding-top: 0;">

	  <div class="content" id="content">
        
  
 
  <div class="rfcmarkup">
    <div class="noprint" style="height: 6px;">
      <div onmouseover="this.style.cursor='pointer';"
         onclick="showLegend();"
         onmouseout="hideLegend()"
         style="height: 6px; min-height: 6px; width: 96ex; position: absolute; margin-top:0; "
         class="meta-info bgblue"
         title="Click for colour legend." >&nbsp;</div>
      <div id="legend"
           class="meta-info noprint pre legend"
           style="position:absolute; top: 4px; left: 4ex; visibility:hidden; background-color: white; padding: 4px 9px 5px 7px; border: solid #345 1px; "
           onmouseover="showLegend();"
           onmouseout="hideLegend();">
      </div>
    </div>

    
      <div class="noprint">
	 <pre class="pre meta-info">[<a href="https://datatracker.ietf.org" title="Document search and retrieval page">Search</a>] [<a href="https://www.rfc-editor.org/rfc/rfc7160.txt" title="Plaintext version of this document">txt</a>|<a href="https://www.rfc-editor.org/rfc/rfc7160.html" title="HTML version of this document, from XML2RFC">html</a>|<a href="https://www.rfc-editor.org/rfc/pdfrfc/rfc7160.txt.pdf" title="PDF version of this document">pdf</a>|<a href="/doc/rfc7160/bibtex/" title="BibTex entry for this document">bibtex</a>] [<a href="/doc/rfc7160/" title="Datatracker information for this document">Tracker</a>] [<a href="/group/avtext/" title="The working group handling this document">WG</a>] [<a href="mailto:draft-ietf-avtext-multiple-clock-rates@ietf.org?subject=draft-ietf-avtext-multiple-clock-rates" title="Send email to the document authors">Email</a>] [<a href="https://www.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-avtext-multiple-clock-rates-11.txt" title="Inline diff (wdiff)">Diff1</a>] [<a href="https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-multiple-clock-rates-11.txt" title="Side-by-side diff">Diff2</a>] [<a href="https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-avtext-multiple-clock-rates-11.txt" title="Run an idnits check of this document">Nits</a>]

From: <a href="/doc/html/draft-ietf-avtext-multiple-clock-rates-11">draft-ietf-avtext-multiple-clock-rates-11</a>        Proposed Standard</pre>
      </div>
    

    <div class="draftcontent">
    <pre>Internet Engineering Task Force (IETF)                 M. Petit-Huguenin
Request for Comments: 7160                            Impedance Mismatch
Updates: <a href="/doc/html/rfc3550">3550</a>                                               G. Zorn, Ed.
Category: Standards Track                                    Network Zen
ISSN: 2070-1721                                               April 2014


           <span class="h1">Support for Multiple Clock Rates in an RTP Session</span>

Abstract

   This document clarifies the RTP specification regarding the use of
   different clock rates in an RTP session.  It also provides guidance
   on how legacy RTP implementations that use multiple clock rates can
   interoperate with RTP implementations that use the algorithm
   described in this document.  It updates <a href="/doc/html/rfc3550">RFC 3550</a>.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in <a href="/doc/html/rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="https://www.rfc-editor.org/info/rfc7160">http://www.rfc-editor.org/info/rfc7160</a>.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="/doc/html/bcp78">BCP 78</a> and the IETF Trust&#x27;s Legal
   Provisions Relating to IETF Documents
   (<a href="https://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.






<span class="grey">Petit-Huguenin &amp; Zorn        Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="/doc/html/rfc7160">RFC 7160</a>                  Multiple Clock Rates                April 2014</span>


Table of Contents

   <a href="#section-1">1</a>.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-2">2</a>
   <a href="#section-2">2</a>.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-4">4</a>
   <a href="#section-3">3</a>.  Legacy RTP  . . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-4">4</a>
     <a href="#section-3.1">3.1</a>.  Different SSRC  . . . . . . . . . . . . . . . . . . . . .   <a href="#page-4">4</a>
     <a href="#section-3.2">3.2</a>.  Same SSRC . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-5">5</a>
       <a href="#section-3.2.1">3.2.1</a>.  Monotonic Timestamps  . . . . . . . . . . . . . . . .   <a href="#page-5">5</a>
       <a href="#section-3.2.2">3.2.2</a>.  Non-monotonic Timestamps  . . . . . . . . . . . . . .   <a href="#page-6">6</a>
   <a href="#section-4">4</a>.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-6">6</a>
     <a href="#section-4.1">4.1</a>.  RTP Sender (with RTCP)  . . . . . . . . . . . . . . . . .   <a href="#page-6">6</a>
     <a href="#section-4.2">4.2</a>.  RTP Sender (without RTCP) . . . . . . . . . . . . . . . .   <a href="#page-6">6</a>
     <a href="#section-4.3">4.3</a>.  RTP Receiver  . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-7">7</a>
   <a href="#section-5">5</a>.  Security Considerations . . . . . . . . . . . . . . . . . . .   <a href="#page-7">7</a>
   <a href="#section-6">6</a>.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-8">8</a>
   <a href="#section-7">7</a>.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-8">8</a>
     <a href="#section-7.1">7.1</a>.  Normative References  . . . . . . . . . . . . . . . . . .   <a href="#page-8">8</a>
     <a href="#section-7.2">7.2</a>.  Informative References  . . . . . . . . . . . . . . . . .   <a href="#page-8">8</a>
   <a href="#appendix-A">Appendix A</a>.  Example Values . . . . . . . . . . . . . . . . . . .  <a href="#page-10">10</a>
   <a href="#appendix-B">Appendix B</a>.  Using a Fixed Clock Rate . . . . . . . . . . . . . .  <a href="#page-12">12</a>
   <a href="#appendix-C">Appendix C</a>.  Behavior of Legacy Implementations . . . . . . . . .  <a href="#page-12">12</a>
     <a href="#appendix-C.1">C.1</a>.  libccrtp 2.0.2  . . . . . . . . . . . . . . . . . . . . .  <a href="#page-12">12</a>
     <a href="#appendix-C.2">C.2</a>.  libmediastreamer0 2.6.0 . . . . . . . . . . . . . . . . .  <a href="#page-12">12</a>
     <a href="#appendix-C.3">C.3</a>.  libpjmedia 1.0  . . . . . . . . . . . . . . . . . . . . .  <a href="#page-13">13</a>
     <a href="#appendix-C.4">C.4</a>.  Android RTP Stack 4.0.3 . . . . . . . . . . . . . . . . .  <a href="#page-13">13</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   The clock rate is a parameter of the payload format as identified in
   RTP and RTCP (RTP Control Protocol) by the payload type value.  It is
   often defined as being the same as the sampling rate but that is not
   always the case (see, for example, the G722 and MPA audio codecs
   [<a href="/doc/html/rfc3551" title="&quot;RTP Profile for Audio and Video Conferences with Minimal Control&quot;">RFC3551</a>]).

   An RTP sender can switch between different payloads during the
   lifetime of an RTP session and because clock rates are defined by
   payload format, it is possible that the clock rate will also vary
   during an RTP session.  Schulzrinne, et al. [<a href="/doc/html/rfc3550" title="&quot;RTP: A Transport Protocol for Real-Time Applications&quot;">RFC3550</a>] lists using
   multiple clock rates as one of the reasons to not use different
   payloads on the same Synchronization Source (SSRC).  Unfortunately,
   this advice has not always been followed and some RTP implementations
   change the payload in the same SSRC, even if the different payloads
   use different clock rates.








<span class="grey">Petit-Huguenin &amp; Zorn        Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="/doc/html/rfc7160">RFC 7160</a>                  Multiple Clock Rates                April 2014</span>


   This creates three problems:

   o  The method used to calculate the RTP timestamp field in an RTP
      packet is underspecified.

   o  When the same SSRC is used for different clock rates, it is
      difficult to know what clock rate was used for the RTP timestamp
      field in an RTCP Sender Report (SR) packet.

   o  When the same SSRC is used for different clock rates, it is
      difficult to know what clock rate was used for the interarrival
      jitter field in an RTCP Receiver Report (RR) packet.

   Table 1 contains a non-exhaustive list of fields in RTCP packets that
   uses a clock rate as a unit:

          +---------------------+------------------+------------+
          | Field name          | RTCP packet type | Reference  |
          +---------------------+------------------+------------+
          | RTP timestamp       | SR               | [<a href="/doc/html/rfc3550" title="&quot;RTP: A Transport Protocol for Real-Time Applications&quot;">RFC3550</a>]  |
          |                     |                  |            |
          | Interarrival jitter | RR               | [<a href="/doc/html/rfc3550" title="&quot;RTP: A Transport Protocol for Real-Time Applications&quot;">RFC3550</a>]  |
          |                     |                  |            |
          | min_jitter          | XR Summary Block | [<a href="/doc/html/rfc3611" title="&quot;RTP Control Protocol Extended Reports (RTCP XR)&quot;">RFC3611</a>]  |
          |                     |                  |            |
          | max_jitter          | XR Summary Block | [<a href="/doc/html/rfc3611" title="&quot;RTP Control Protocol Extended Reports (RTCP XR)&quot;">RFC3611</a>]  |
          |                     |                  |            |
          | mean_jitter         | XR Summary Block | [<a href="/doc/html/rfc3611" title="&quot;RTP Control Protocol Extended Reports (RTCP XR)&quot;">RFC3611</a>]  |
          |                     |                  |            |
          | dev_jitter          | XR Summary Block | [<a href="/doc/html/rfc3611" title="&quot;RTP Control Protocol Extended Reports (RTCP XR)&quot;">RFC3611</a>]  |
          |                     |                  |            |
          | Interarrival jitter | IJ               | [<a href="/doc/html/rfc5450" title="&quot;Transmission Time Offsets in RTP Streams&quot;">RFC5450</a>]  |
          |                     |                  |            |
          | RTP timestamp       | SMPTETC          | [<a href="/doc/html/rfc5484" title="&quot;Associating Time-Codes with RTP Streams&quot;">RFC5484</a>]  |
          |                     |                  |            |
          | Jitter              | RSI Jitter Block | [<a href="/doc/html/rfc5760" title="&quot;RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback&quot;">RFC5760</a>]  |
          |                     |                  |            |
          | Median jitter       | RSI Stats Block  | [<a href="/doc/html/rfc5760" title="&quot;RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback&quot;">RFC5760</a>]  |
          +---------------------+------------------+------------+

                                  Table 1

   <a href="#section-3">Section 3</a> and its subsections try to list all of the algorithms known
   to be used in existing RTP implementations at the time of writing.
   These sections are not normative.

   <a href="#section-4">Section 4</a> and its subsections recommend a unique algorithm that
   modifies <a href="/doc/html/rfc3550">RFC 3550</a>.  These sections are normative.



<span class="grey">Petit-Huguenin &amp; Zorn        Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="/doc/html/rfc7160">RFC 7160</a>                  Multiple Clock Rates                April 2014</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Terminology</span>

   The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
   &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this
   document are to be interpreted as described in <a href="/doc/html/rfc2119">RFC 2119</a> [<a href="/doc/html/rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

   In addition, this document uses the following terms:

   Clock rate     The multiplier used to convert from a wallclock value
                  in seconds to an equivalent RTP timestamp value
                  (without the fixed random offset).  Note that <a href="/doc/html/rfc3550">RFC 3550</a>
                  uses various terms like &quot;clock frequency&quot;, &quot;media
                  clock rate&quot;, &quot;timestamp unit&quot;, &quot;timestamp frequency&quot;,
                  and &quot;RTP timestamp clock rate&quot; as synonymous to clock
                  rate.

   RTP Sender     A logical network element that sends RTP packets,
                  sends RTCP SR packets, and receives RTCP reception
                  report blocks.

   RTP Receiver   A logical network element that receives RTP packets,
                  receives RTCP SR packets, and sends RTCP reception
                  report blocks.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Legacy RTP</span>

   The following sections describe the various ways in which legacy RTP
   implementations behave when multiple clock rates are used.  &quot;Legacy
   RTP&quot; refers to <a href="/doc/html/rfc3550">RFC 3550</a> without the modifications introduced by this
   document.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Different SSRC</span>

   One way of managing multiple clock rates is to use a different SSRC
   for each different clock rate, as in this case there is no ambiguity
   on the clock rate used by fields in the RTCP packets.  This method
   also seems to be the original intent of RTP as can be deduced from
   points 2 and 3 of <a href="/doc/html/rfc3550#section-5.2">Section&nbsp;5.2 of RFC 3550</a>.

   On the other hand, changing the SSRC can be a problem for some
   implementations designed to work only with unicast IP addresses,
   where having multiple SSRCs is considered a corner case.  Lip
   synchronization can also be a problem in the interval between the
   beginning of the new stream and the first RTCP SR packet.







<span class="grey">Petit-Huguenin &amp; Zorn        Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="/doc/html/rfc7160">RFC 7160</a>                  Multiple Clock Rates                April 2014</span>


<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Same SSRC</span>

   The simplest way to manage multiple clock rates is to use the same
   SSRC for all of the payload types regardless of the clock rates.

   Unfortunately, there is no clear definition on how the RTP timestamp
   should be calculated in this case.  The following subsections present
   the algorithms currently in use.

<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>.  Monotonic Timestamps</span>

   This method of calculating the RTP timestamp ensures that the value
   increases monotonically.  The formula used by this method is as
   follows:

   timestamp = previous_timestamp
               + (current_capture_time - previous_capture_time)
               * current_clock_rate

   The problem with this method is that the jitter calculation on the
   receiving side gives an invalid result during the transition between
   two clock rates, as shown in Table 2 (Appendix A).  The capture and
   arrival time are measured in seconds, starting at the beginning of
   the capture of the first packet; clock rate is measured in Hz; the
   RTP timestamp does not include the random offset; and the transit,
   jitter, and average jitter use the clock rate as a unit.

   Calculating the correct transit time on the receiving side can be
   done by using the following formulas:

   1.  current_capture_time = (current_timestamp - previous_timestamp) /
       current_clock_rate + previous_capture_time

   2.  transit = current_clock_rate * (arrival_time -
       current_capture_time)

   3.  previous_capture_time = current_capture_time

   The main problem with this method, in addition to the fact that the
   jitter calculation described in <a href="/doc/html/rfc3550">RFC 3550</a> cannot be used, is that it
   is dependent on the previous RTP packets, which can be reordered or
   lost in the network.









<span class="grey">Petit-Huguenin &amp; Zorn        Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="/doc/html/rfc7160">RFC 7160</a>                  Multiple Clock Rates                April 2014</span>


<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>.  Non-monotonic Timestamps</span>

   An alternate way of generating the RTP timestamps is to use the
   following formula:

                   timestamp = capture_time * clock_rate

   With this formula, the jitter calculation is correct but the RTP
   timestamp values are no longer increasing monotonically as shown in
   Table 3 (Appendix A).  <a href="/doc/html/rfc3550">RFC 3550</a> states that &quot;[t]he sampling instant
   MUST be derived from a clock that increments monotonically . . .&quot;,
   but it does not say that the RTP timestamp must increment
   monotonically.

   The advantage with this method is that it works with the jitter
   calculation described in <a href="/doc/html/rfc3550">RFC 3550</a>, as long as the correct clock rates
   are used.  It seems that this is what most implementations are using
   (based on a survey done at SIPit26 and on a survey of open source
   implementations, see <a href="#appendix-C">Appendix C</a>).

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Recommendations</span>

   The following subsections describe behavioral recommendations for RTP
   senders (with and without RTCP) and RTP receivers.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  RTP Sender (with RTCP)</span>

   An RTP Sender with RTCP turned on MUST use a different SSRC for each
   different clock rate.  An RTCP BYE MUST be sent and a new SSRC MUST
   be used if the clock rate switches back to a value already seen in
   the RTP stream.

   To accelerate lip synchronization, the next compound RTCP packet sent
   by the RTP sender MUST contain multiple SR packets, the first one
   containing the mapping for the current clock rate and the subsequent
   SR packet(s) containing the mapping for the other clock rates seen
   during the last period.

   The RTP extension defined by Perkins &amp; Schierl [<a href="/doc/html/rfc6051" title="&quot;Rapid Synchronisation of RTP Flows&quot;">RFC6051</a>] MAY be used
   to accelerate the synchronization.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  RTP Sender (without RTCP)</span>

   An RTP Sender with RTCP turned off (i.e., having set the RTP Sender
   and RTP Receiver bandwidth modifiers [<a href="/doc/html/rfc3556" title="&quot;Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth&quot;">RFC3556</a>] to 0) SHOULD use a
   different SSRC for each different clock rate but MAY use different
   clock rates on the same SSRC as long as the RTP timestamp is
   calculated as explained below:



<span class="grey">Petit-Huguenin &amp; Zorn        Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="/doc/html/rfc7160">RFC 7160</a>                  Multiple Clock Rates                April 2014</span>


   Each time the clock rate changes, the start_offset and capture_start
   values are calculated with the following formulas:

   start_offset += (capture_time - capture_start) * previous_clock_rate
   capture_start = capture_time

   For the first RTP packet, the values are initialized with the
   following values:

                   start_offset = random_initial_offset
                   capture_start = capture_time

   After eventually updating these values, the RTP timestamp is
   calculated with the following formula:

          timestamp = (capture_time - capture_start) * clock_rate
                      + start_offset

   Note that in all the formulas, capture_start is the first instant
   that the new timestamp rate is used.  The output of the above method
   is exemplified in Table 4 (Appendix A).

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  RTP Receiver</span>

   An RTP Receiver MUST calculate the jitter using the following
   formula:

         D(i,j) = (arrival_time_j * clock_rate_i - timestamp_j)
                  - (arrival_time_i * clock_rate_i - timestamp_i)

   An RTP Receiver MUST be able to handle a compound RTCP packet with
   multiple SR packets.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Security Considerations</span>

   When the algorithm described in <a href="#section-4.1">Section 4.1</a> is used, the security
   considerations described in <a href="/doc/html/rfc3550">RFC 3550</a> apply.

   The algorithm described in <a href="#section-4.2">Section 4.2</a> is new and so its security
   properties were not considered in <a href="/doc/html/rfc3550">RFC 3550</a>.  Although the RTP
   timestamp is initialized with a random value like before, the
   timestamp value depends on the current and previous clock rates; this
   may or may not introduce a security vulnerability in the protocol.








<span class="grey">Petit-Huguenin &amp; Zorn        Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="/doc/html/rfc7160">RFC 7160</a>                  Multiple Clock Rates                April 2014</span>


<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Acknowledgements</span>

   Thanks to Colin Perkins, Ali C. Begen, Harald Alvestrand, Qin Wu,
   Jonathan Lennox, Barry Leiba, David Harrington, Stephen Farrell,
   Spencer Dawkins, Wassim Haddad, and Magnus Westerlund for comments,
   suggestions, and questions that helped to improve this document.

   Thanks to Bo Burman, who provided the values in Table 4 of
   <a href="#appendix-A">Appendix A</a>.

   Thanks to Robert Sparks and the attendees of SIPit 26 for the survey
   on multiple clock rates interoperability.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  References</span>

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  Normative References</span>

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., &quot;Key words for use in RFCs to Indicate
              Requirement Levels&quot;, <a href="/doc/html/bcp14">BCP 14</a>, <a href="/doc/html/rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC3550">RFC3550</a>]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, &quot;RTP: A Transport Protocol for Real-Time
              Applications&quot;, STD 64, <a href="/doc/html/rfc3550">RFC 3550</a>, July 2003.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  Informative References</span>

   [<a id="ref-AVT-VAR-RATE">AVT-VAR-RATE</a>]
              Wenger, S. and C. Perkins, &quot;RTP Timestamp Frequency for
              Variable Rate Audio Codecs&quot;, Work in Progress, October
              2004.

   [<a id="ref-RFC3551">RFC3551</a>]  Schulzrinne, H. and S. Casner, &quot;RTP Profile for Audio and
              Video Conferences with Minimal Control&quot;, STD 65, <a href="/doc/html/rfc3551">RFC 3551</a>,
              July 2003.

   [<a id="ref-RFC3556">RFC3556</a>]  Casner, S., &quot;Session Description Protocol (SDP) Bandwidth
              Modifiers for RTP Control Protocol (RTCP) Bandwidth&quot;, <a href="/doc/html/rfc3556">RFC</a>
              <a href="/doc/html/rfc3556">3556</a>, July 2003.

   [<a id="ref-RFC3611">RFC3611</a>]  Friedman, T., Caceres, R., and A. Clark, &quot;RTP Control
              Protocol Extended Reports (RTCP XR)&quot;, <a href="/doc/html/rfc3611">RFC 3611</a>, November
              2003.

   [<a id="ref-RFC5450">RFC5450</a>]  Singer, D. and H. Desineni, &quot;Transmission Time Offsets in
              RTP Streams&quot;, <a href="/doc/html/rfc5450">RFC 5450</a>, March 2009.

   [<a id="ref-RFC5484">RFC5484</a>]  Singer, D., &quot;Associating Time-Codes with RTP Streams&quot;, <a href="/doc/html/rfc5484">RFC</a>
              <a href="/doc/html/rfc5484">5484</a>, March 2009.



<span class="grey">Petit-Huguenin &amp; Zorn        Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="/doc/html/rfc7160">RFC 7160</a>                  Multiple Clock Rates                April 2014</span>


   [<a id="ref-RFC5760">RFC5760</a>]  Ott, J., Chesterfield, J., and E. Schooler, &quot;RTP Control
              Protocol (RTCP) Extensions for Single-Source Multicast
              Sessions with Unicast Feedback&quot;, <a href="/doc/html/rfc5760">RFC 5760</a>, February 2010.

   [<a id="ref-RFC6051">RFC6051</a>]  Perkins, C. and T. Schierl, &quot;Rapid Synchronisation of RTP
              Flows&quot;, <a href="/doc/html/rfc6051">RFC 6051</a>, November 2010.













































<span class="grey">Petit-Huguenin &amp; Zorn        Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="/doc/html/rfc7160">RFC 7160</a>                  Multiple Clock Rates                April 2014</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Example Values</span>

   The following tables illustrate the timestamp and jitter values
   produced when the various methods discussed in the text are used.

   The values shown are purely exemplary, illustrative, and non-
   normative.

   +-------+-------+-----------+---------+---------+--------+----------+
   | Capt. | Clock | RTP       | Arrival | Transit | Jitter | Average  |
   | time  | rate  | timestamp | time    |         |        | jitter   |
   +-------+-------+-----------+---------+---------+--------+----------+
   | 0     | 8000  | 0         | 0.1     | 800     |        |          |
   |       |       |           |         |         |        |          |
   | 0.02  | 8000  | 160       | 0.12    | 800     | 0      | 0        |
   |       |       |           |         |         |        |          |
   | 0.04  | 8000  | 320       | 0.14    | 800     | 0      | 0        |
   |       |       |           |         |         |        |          |
   | 0.06  | 8000  | 480       | 0.16    | 800     | 0      | 0        |
   |       |       |           |         |         |        |          |
   | 0.08  | 16000 | 800       | 0.18    | 2080    | 480    | 30       |
   |       |       |           |         |         |        |          |
   | 0.1   | 16000 | 1120      | 0.2     | 2080    | 0      | 28       |
   |       |       |           |         |         |        |          |
   | 0.12  | 16000 | 1440      | 0.22    | 2080    | 0      | 26       |
   |       |       |           |         |         |        |          |
   | 0.14  | 8000  | 1600      | 0.24    | 320     | 720    | 70       |
   |       |       |           |         |         |        |          |
   | 0.16  | 8000  | 1760      | 0.26    | 320     | 0      | 65       |
   +-------+-------+-----------+---------+---------+--------+----------+

                       Table 2: Monotonic Timestamps



















<span class="grey">Petit-Huguenin &amp; Zorn        Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="/doc/html/rfc7160">RFC 7160</a>                  Multiple Clock Rates                April 2014</span>


   +-------+-------+-----------+---------+---------+--------+----------+
   | Capt. | Clock | RTP       | Arrival | Transit | Jitter | Average  |
   | time  | rate  | timestamp | time    |         |        | jitter   |
   +-------+-------+-----------+---------+---------+--------+----------+
   | 0     | 8000  | 0         | 0.1     | 800     |        |          |
   |       |       |           |         |         |        |          |
   | 0.02  | 8000  | 160       | 0.12    | 800     | 0      | 0        |
   |       |       |           |         |         |        |          |
   | 0.04  | 8000  | 320       | 0.14    | 800     | 0      | 0        |
   |       |       |           |         |         |        |          |
   | 0.06  | 8000  | 480       | 0.16    | 800     | 0      | 0        |
   |       |       |           |         |         |        |          |
   | 0.08  | 16000 | 1280      | 0.18    | 1600    | 0      | 0        |
   |       |       |           |         |         |        |          |
   | 0.1   | 16000 | 1600      | 0.2     | 1600    | 0      | 0        |
   |       |       |           |         |         |        |          |
   | 0.12  | 16000 | 1920      | 0.22    | 1600    | 0      | 0        |
   |       |       |           |         |         |        |          |
   | 0.14  | 8000  | 1120      | 0.24    | 800     | 0      | 0        |
   |       |       |           |         |         |        |          |
   | 0.16  | 8000  | 1280      | 0.26    | 800     | 0      | 0        |
   +-------+-------+-----------+---------+---------+--------+----------+

                     Table 3: Non-monotonic Timestamps



























<span class="grey">Petit-Huguenin &amp; Zorn        Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="/doc/html/rfc7160">RFC 7160</a>                  Multiple Clock Rates                April 2014</span>


   +-------+-------+-----------+---------+---------+--------+----------+
   | Capt. | Clock | RTP       | Arrival | Transit | Jitter | Average  |
   | time  | rate  | timestamp | time    |         |        | jitter   |
   +-------+-------+-----------+---------+---------+--------+----------+
   | 0     | 8000  | 0         | 0.1     | 800     |        |          |
   |       |       |           |         |         |        |          |
   | 0.02  | 8000  | 160       | 0.12    | 800     | 0      | 0        |
   |       |       |           |         |         |        |          |
   | 0.04  | 8000  | 320       | 0.14    | 800     | 0      | 0        |
   |       |       |           |         |         |        |          |
   | 0.06  | 8000  | 480       | 0.16    | 800     | 0      | 0        |
   |       |       |           |         |         |        |          |
   | 0.08  | 16000 | 640       | 0.18    | 1600    | 0      | 0        |
   |       |       |           |         |         |        |          |
   | 0.1   | 16000 | 960       | 0.2     | 1600    | 0      | 0        |
   |       |       |           |         |         |        |          |
   | 0.12  | 16000 | 1280      | 0.22    | 1600    | 0      | 0        |
   |       |       |           |         |         |        |          |
   | 0.14  | 8000  | 1600      | 0.24    | 320     | 0      | 0        |
   |       |       |           |         |         |        |          |
   | 0.16  | 8000  | 1760      | 0.26    | 320     | 0      | 0        |
   +-------+-------+-----------+---------+---------+--------+----------+

         Table 4: Recommended Method for RTP Sender (without RTCP)

<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>.  Using a Fixed Clock Rate</span>

   An alternate way of fixing the issue with using multiple clock rates
   was proposed by Wenger and Perkins [<a href="#ref-AVT-VAR-RATE">AVT-VAR-RATE</a>].  This document
   proposed to define a unified clock rate, but the proposal was
   rejected at IETF 61.

<span class="h2"><a class="selflink" id="appendix-C" href="#appendix-C">Appendix C</a>.  Behavior of Legacy Implementations</span>

<span class="h3"><a class="selflink" id="appendix-C.1" href="#appendix-C.1">C.1</a>.  libccrtp 2.0.2</span>

   This library uses the formula described in <a href="#section-3.2.2">Section 3.2.2</a>.

   Note that this library uses gettimeofday(2) which is not guaranteed
   to increment monotonically (e.g., when the clock is adjusted by NTP).

<span class="h3"><a class="selflink" id="appendix-C.2" href="#appendix-C.2">C.2</a>.  libmediastreamer0 2.6.0</span>

   This library (which uses the oRTP library) uses the formula described
   in <a href="#section-3.2.2">Section 3.2.2</a>.

   Note that in some environments this library uses gettimeofday(2),
   which is not guaranteed to increment monotonically.



<span class="grey">Petit-Huguenin &amp; Zorn        Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="/doc/html/rfc7160">RFC 7160</a>                  Multiple Clock Rates                April 2014</span>


<span class="h3"><a class="selflink" id="appendix-C.3" href="#appendix-C.3">C.3</a>.  libpjmedia 1.0</span>

   This library uses the formula described in <a href="#section-3.2.2">Section 3.2.2</a>.

<span class="h3"><a class="selflink" id="appendix-C.4" href="#appendix-C.4">C.4</a>.  Android RTP Stack 4.0.3</span>

   This library changes the SSRC each time the format changes, as
   described in <a href="#section-3.1">Section 3.1</a>.

Authors&#x27; Addresses

   Marc Petit-Huguenin
   Impedance Mismatch

   EMail: petithug@acm.org


   Glen Zorn (editor)
   Network Zen
   227/358 Thanon Sanphawut
   Bang Na, Bangkok  10260
   Thailand

   Phone: +66 (0) 8-1000-4155
   EMail: glenzorn@gmail.com


























Petit-Huguenin &amp; Zorn        Standards Track                   [Page 13]
</pre>
    </div>

  </div>


        
	  </div>

	

	

    </div>

      
    <script type="text/javascript"><!--
    var legend_html = "Colour legend:<br /> \
     <table> \
        <tr><td>Unknown:</td>                   <td><span class='cplate bgwhite'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> \
        <tr><td>Draft:</td>                     <td><span class='cplate bgred'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> \
        <tr><td>Informational:</td>             <td><span class='cplate bgorange'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> \
        <tr><td>Experimental:</td>              <td><span class='cplate bgyellow'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> \
        <tr><td>Best Common Practice:</td>      <td><span class='cplate bgmagenta'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> \
        <tr><td>Proposed Standard:</td>         <td><span class='cplate bgblue'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> \
        <tr><td>Draft Standard (old designation):</td> <td><span class='cplate bgcyan'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> \
        <tr><td>Internet Standard:</td>         <td><span class='cplate bggreen'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> \
        <tr><td>Historic:</td>                  <td><span class='cplate bggrey'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> \
        <tr><td>Obsolete:</td>                  <td><span class='cplate bgbrown'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> \
    </table>";
    function showLegend() {
        var elem = document.getElementById('legend');
        elem.innerHTML = legend_html
        elem.style.visibility='visible';
    }
    function hideLegend() {
        var elem = document.getElementById('legend');
        elem.style.visibility='hidden';
        elem.innerHTML = "";
    }
    // -->
    </script>

  </body>
</html>